\section{Posibles Mejoras}
Por cuestiones de tiempo o simplicidad hay mejoras que estuvieron presentes pero no las implementamos a continuación mencionaremos 
algunas de ellas:

\textbf{El entrenamiento:} El entrenamiento es conocido por el seguidor, y sabe contestar mensajes como proximaFase o hayProximaFase. 
Lo pensamos desde el sentido de antropomorfismo de clases, pero bien podría ser otro el responsable, es decir, podría existir un 
objeto que conozca al entrenamiento y lleve cuenta de su estado.

\textbf{El controlador de Velocidad:} Cuando se actualiza el controlador, pide la fase actual para poder ver si la velocidad calculada está 
en rango. Para determinarlo, hace una comparación entre lo que calculó y los umbrales conocidos. Pero esta comparación podría sacarse,
 es decir podría haber otro objeto que subclasifique en tres rangos y buscar cual comparador es el adecuado, 
para decidir si el corredor va bien o debe aumentar o disminuir la velocidad. Se omitió esta solución porque si bien es purista, 
no nos da una gran ventaja ni gran extensibilidad.

Podría haber una clase abstracta del subclasifique el gestor de mapas por si el día de mañana aparecen varios tipos de mapa.

Si se quisiera registrar el tiempo de finalización de un entrenamiento, el seguidor podría contar con un cronómetro capaz de 
pedirle el tiempo transcurrido, pausarlo o reiniciarlo según se necesite.

\textbf{El seguidor de entrenamiento:} A simple vista el seguidor de entrenamiento parece un objeto sobrecargado de responsabilidades. 
Una posibilidad que surgió es separar un Objeto encargado de disparar las colaboraciones y otro de monitorear el entrenamiento, 
algo así como un Motor De Entrenamiento y Un Seguidor De Entrenamiento. El motor se encargaría de avanzarlo de fase y ejecutar 
las colaboraciones necesarias para que el entrenamiento, o más bien, estado de entrenamiento, mute y el seguidor por otra parte se 
encargaría solo de avisos, cálculos u observaciones de datos.

